|
|
||||
| PS-CA v2.1.0 DFT-Ballot Submissions (InfoRMS) | ||||
| Displaying 114 issues at 18/Aug/25 12:24 PM. |
| Key | Summary | Description | Resolution | Resolution Description |
|---|---|---|---|---|
| PS-83 | Suggestion on adding granularity in defining MustSupport elements for: MedicationRequest.timing |
Summary: Suggestion on adding granularity in defining MustSupport elements for: MedicationRequest.timing
Existing Wording: Proposed Wording: Comment: The level of granularity for MustSupport (MS) elements remains an ongoing issue. During the Patient Summary LPR in Ontario the EMR vendors requested for OH to provide additional guidance on what specific child elements to be included in their PS data contribution. It would be beneficial for the PS-CA WG to collaborate and explore opportunities to define more specific guidance to improve consistency and reduce variations between the implementations across jurisdictions Submitted by: Cindy Jiang ([email protected]) Philip Sales ([email protected]) OntarioHealth |
Not Persuasive with Modification | Align with CA Core and undertake the broader review in concert with review of IPS Obligations |
| PS-84 | Suggestion on adding granularity in defining MustSupport elements for: MedicaitonStatement.timing |
Summary: Suggestion on adding granularity in defining MustSupport elements for: MedicaitonStatement.timing
Comment: The level of granularity for MustSupport (MS) elements remains an ongoing issue. During the Patient Summary LPR in Ontario the EMR vendors requested for OH to provide additional guidance on what specific child elements to be included in their PS data contribution. It would be beneficial for the PS-CA WG to collaborate and explore opportunities to define more specific guidance to improve consistency and reduce variations between the implementations across jurisdictions Submitted by: Cindy Jiang ([email protected]) Philip Sales ([email protected]) OntarioHealth |
Not Persuasive with Modification | Align with CA Core and undertake the broader review in concert with review of IPS Obligations |
| PS-85 | Suggestion on adding granularity in defining MustSupport elements for: Patient.address |
Summary: Suggestion on adding granularity in defining MustSupport elements for: Patient.address
Existing Wording: Proposed Wording: Comment: The level of granularity for MustSupport (MS) elements remains an ongoing issue. During the Patient Summary LPR in Ontario the EMR vendors requested for OH to provide additional guidance on what specific child elements to be included in their PS data contribution. It would be beneficial for the PS-CA WG to collaborate and explore opportunities to define more specific guidance to improve consistency and reduce variations between the implementations across jurisdictions Submitted by: Cindy Jiang ([email protected]) Philip Sales ([email protected]) OntarioHealth |
Persuasive | Add MS to elements to align with CA-Core |
| PS-86 | Suggestion on adding granularity in defining MustSupport elements for: (Patient/Practitioner).telecom |
Summary: Suggestion on adding granularity in defining MustSupport elements for: (Patient/Practitioner).telecom
Existing Wording: Proposed Wording: Comment: The level of granularity for MustSupport (MS) elements remains an ongoing issue. During the Patient Summary LPR in Ontario the EMR vendors requested for OH to provide additional guidance on what specific child elements to be included in their PS data contribution. It would be beneficial for the PS-CA WG to collaborate and explore opportunities to define more specific guidance to improve consistency and reduce variations between the implementations across jurisdictions Submitted by: Cindy Jiang ([email protected]) Philip Sales ([email protected]) OntarioHealth |
Persuasive with Modification | Align with CA Core, adding MS to Patient.telecom but not Practitioner.telecom |
| PS-87 | Suggestion on using of pan-Canadian canonical url for valuesets instead of project-specific url. |
Summary: Suggestion on using of pan-Canadian canonical url for valuesets instead of project-specific url.
Existing Wording: Proposed Wording: Comment: Suggestion on using project-agnostic, pan-Canadian URLs for certain value sets in elements like Condition.code, Medication.code, and Procedure.code. This would help support broader reuse beyond PS-CA. Examples include: - LicensedNaturalHealthProducts - HealthCanadaNaturalProductNumber - ICD10CAAllCode - ICD9CMAllCode - CCIAllCode Submitted by: Philip Sales ([email protected]) OntarioHealth |
Persuasive | Managed by CIHI and Health Canada and Infoway has no license agreement at the moment; that is why these are project specific. They will be switched once licensing is in place. |
| PS-88 | Suggestion on having clear guidance on the alignment between 1..1 elements and non-MustSupport flags in PS-CA against CA Core to avoid implementation ambiguity. |
Summary: Suggestion on having clear guidance on the alignment between 1..1 elements and non-MustSupport flags in PS-CA against CA Core to avoid implementation ambiguity.
Existing Wording: Proposed Wording: Comment: There seems to be a mismatch in how elements marked as 1..1 (mandatory) but not marked as MustSupport are defined in the PS-CA and CA Core profiles. Clear and consistent guidance is needed on how jurisdictional profiles and implementers should treat these elements. Submitted by: Philip Sales ([email protected]) OntarioHealth |
Considered for Future Use | Defer until CA Core discussion is complete and that we can be more explicit with Obligations |
| PS-89 | Guidance on when to deprecate the UV-IPS Absent or Unknown value sets and transition to using SNOMED CT "No known" clinical codes within Canadian CT-CA subsets. |
Summary: Guidance on when to deprecate the UV-IPS Absent or Unknown value sets and transition to using SNOMED CT "No known" clinical codes within Canadian CT-CA subsets.
Existing Wording: Proposed Wording: Comment: Guidance on the direction when to deprecate the UV-IPS absent-or-unknown valueSets, including: AbsentOrUnknownAllergiesUvIps AbsentOrUnknownDevicesUvIps AbsentOrUnknownImmunizationUvIps AbsentOrUnknownMedicationUvIps AbsentOrUnknownProblemsUvIps AbsentOrUnknownProceduresUvIps and the addition of the new SNOMED CT "No known allergies/immunizations/etc" clinical codes to our Canadian CT-CA subsets. Submitted by: Philip Sales ([email protected]) OntarioHealth |
Persuasive | Defer this given this is now an active item for discussion and consultation in the PCHDCF Valueset working group.
We need to consider if there are values that need to be added to the terminology to meet use case as well as any data validation requirements or triggers if a value chosen from the valueset is actually an unknown value. Will the values be coming from one terminology source and not separated in a distinct element or slice present any issues? Given the timelines, this will come out for review in September 2025 as part of Version 2, This would inform the pan Canadian valueset update approach coming out of that review cycle. So we could be looking at the November release or potentially February 2026 to apply changes appropriately. |
| PS-90 | Overlapping SNOMED CT codes in multiple value sets can cause validation errors, especially when the same code appears in both MedicationUvIps and PharmaceuticalBiologicProductAndSubstanceCode. |
Summary: Overlapping SNOMED CT codes in multiple value sets can cause validation errors, especially when the same code appears in both MedicationUvIps and PharmaceuticalBiologicProductAndSubstanceCode.
Existing Wording: Proposed Wording: Comment: Some codes appear in both the MedicationUvIps and PharmaceuticalBiologicProductAndSubstanceCode value sets. Since both value sets reference the same code system (SNOMED CT), this overlap might cause validation errors when a single code exists in both. For example: 1357746006 – Product containing hypochlorous acid 424384000 – Product containing caffeine and glucose Submitted by: Philip Sales ([email protected]) OntarioHealth |
Considered for Future Use | There doesn't seem to be an immediate issue, but should monitor and be informed if there is. |
| PS-91 | Suggestion on following the IPS slicing approach. Lack of explicit slicing in Bundle.entry for PS-CA causes repeated OperationOutcome (OO) messages. |
Summary: Suggestion on following the IPS slicing approach. Lack of explicit slicing in Bundle.entry for PS-CA causes repeated OperationOutcome (OO) messages.
Existing Wording: Proposed Wording: Comment: Understand the reasoning behind PS-CA not adopting the IPS approach of explicitly slicing Bundle.entry by resource type. Without this profiled slices, validation frequently returns multiple OperationOutcome (OO) messages flagged as "slicing information." While these are not warnings or errors, they still generate noise which can be avoided. Adopting the IPS slicing strategy would improve consistency and removes the OO flags. In the Ontario context, all OO responses are logged and recorded in the Data Quality Service (DQS). Without explicit slicing in Bundle.entry, as done in IPS, every PS-ON FHIR payload triggers slicing-related OperationOutcome messages. This leads to a lot of unnecessary noise and floods the DQS. Adopting the IPS slicing approach would help mitigate this. Submitted by: Philip Sales ([email protected]) OntarioHealth |
Persuasive | PSCA will adopt the IPS slicing for Bundle.entry. I.e. add slices of known resources/profiles to reduce messages. Slicing is open so there may still be messages. |
| PS-92 | Direction on the use of .emptyReason in Composition.section to avoid breaking changes. |
Summary: Direction on the use of .emptyReason in Composition.section to avoid breaking changes.
Existing Wording: Proposed Wording: Comment: Clarification on the future alignment with IPS on the direction for the use of .emptyReason in Composition.section. Will this element be flagged as MustSupport, and are there plans to introduce or align with corresponding invariants or constraint rules? This data element may have the potential to introduce a breaking change. Timely guidance and clear direction would be valuable to help avoid future re-work and ensure consistent implementation across jurisdictions. Submitted by: Philip Sales ([email protected]) OntarioHealth |
Persuasive | Allign with IPS, medication, allergies and problems emptyReason set to MS with additional comments indicating obligations for Rx and Sender. |
| PS-93 | Request more prescriptive guidance on the expected content of the .text narrative element to promote consistency |
*Summary:* Request more prescriptive guidance on the expected content of the .text narrative element to promote consistency
Existing Wording: Proposed Wording: {*}Comment{*}: Requesting to provide more prescriptive guidance on the specific data elements that should be included in the .text narrative of FHIR resources. Clear direction will help consistency across vendor implementations and align with the intended purpose of the narrative in Canadian clinical contexts. *Submitted* by: Philip Sales ([email protected]) OntarioHealth |
Unresolved | This is general guidance, beyond PSCA. Consider for inclusion with CA Core |
| PS-94 | MedicationRequest.authored.on - why is this no longer supported? |
Summary: MedicationRequest.authored.on - why is this no longer supported?
Existing Wording: Proposed Wording: Comment: MedicationRequest.authored.on - why is this no longer supported? An EMR or any receiving system needs to know this information. Critical for patient safety, especially in cases where the time the patient took the medication is unknown. Example: Patient was given chemo treatment 5 days prior as a single dose. The chemo treatment is no longer part of the medication statement; therefore not in the current medication list in the EMR. If there is an edge case/rationale where this data is not available, please advise what the edge cases are so we can look at alternate approaches. If this is no longer supported, receiving systems may ignore the data even if sent. Submitted by: Telus Health |
Persuasive | This is a duplicate of 204 |
| PS-95 | Observation (alcohol use) valueQuantity -Why was support removed for ValueQuantity, as opposed to leaving it as optional? |
Summary: Observation (alcohol use) valueQuantity -Why was support removed for ValueQuantity, as opposed to leaving it as optional?
Existing Wording: Proposed Wording: Comment: Observation (alcohol use) valueQuantity - removed support for this. As an implementer, I need to support value(x). Does this mean all implementers need to support all possibilities? valueString? valueTime, ValueSampleData? ValueQuantity? This is not clear in the profile. Why was support removed for ValueQuantity, as opposed to leaving it as optional? Submitted by: Telus Health |
Considered-Question answered | BC can not supply a valueQuantity, thus the MS was removed. One doesn't need to support all the value[x] possibilities; but there should be a implementation decsions made on which to support. |
| PS-96 | Patient Story. Please provide some concrete examples |
Summary: Patient Story. Please provide some concrete examples
Existing Wording: Proposed Wording: Comment: Patient Story. Please provide some concrete examples as provided by the jurisdictions of how this will be used as it is unclear. We would suggest that text and entry should be must support; otherwise, do implementers support all? Submitted by: Telus Health |
Persuasive | Update section description to match that approved for IPS:
The section contains narrative text along with optional resources that express what matters to a patient. This may include needs, strengths, values, concerns and preferences to others providing support and care. Information in this section may include: * My wellness and date * What are the most important things that I want to be known * Date of important elements * Important content to me * Important people to me Any resource type may be used to support narrative. |
| PS-97 | There’s a risk of outdated dose info in the Patient Summary if it's based only on the last prescription. EMRs don’t always update prescriptions when doses change. |
Summary: There’s a risk of outdated dose info in the Patient Summary if it's based only on the last prescription. EMRs don’t always update prescriptions when doses change.
Existing Wording: Proposed Wording: Comment: We recognize that the Patient Summary probably just requires the Current Medication List and not the history of medications. The only flaw in this is if they expect EMRs to base the Current Medication Summary off of the last prescription written for warfarin, then the dose included in the Patient Summary will sometimes be outdated and incorrect, a serious patient harm risk. Again, EMR's do not alter existing prescriptions. Here is a situation where an EMR may put incorrect dose information into a Patient Summary: 1) warfarin is prescribed as 1 mg 3 tablets once daily; 2) the physician in response to a weekly INR test instructs the patient to change the dose to 2 tabs daily; 3) if the Patient Summary Current Medications List is created based on the last prescription for warfarin, the wrong dose will be sent and perhaps administered by the receiving clinician. This is a serious patient harm situation. We recommend that a note be added to the Patient Summary documentation to help vendors avoid this error. Since in the case above the last Medication Request will be the prescription with the old dose information, the vendor must send the correct current warfarin as either a Medication Statement or as a Medication Request that contains the correct current dose (even if there was no new prescription created). Lastly, just as an FYI.. it has been suggested to us in consultation with FHIR experts that to properly convey this data, outside of using notes, one mechanism would be to add provenance that references the medication request, to convey the reason for the change (eg dosage change). This is not part of the patient summary and therefore would not be supported/consumed by recipients. Submitted by: Telus Health Row 17 |
Persuasive | Deferring until we have guidance - Agreed that note can be added, will consult with IPS on the content of the note. IPS is expected to add additional guidance RE understanding the Summarys role. Also consult with Pharmacy SMEs. |
| PS-98 | ValueSets versioning format change impact |
Summary: ValueSets versioning format change impact
Existing Wording: Proposed Wording: Comment: In the change log, you state: The following ValueSets versioning format changed from YYYYMMDD to X.Y.Z (Semantic Versioning) to align with TerminologyService format (semantic): Can you please explain what if any impact this will have on message validation, if the version is specified within the message instance. Submitted by: Telus Health |
Not Persuasive | There is no impact, version is not included in instances, only in value set definitions. |
| PS-99 | Composition.text - Guidance regarding text and section.text |
Summary: Guidance regarding text and section.text
Existing Wording: PS-CA is following IPS guidence regarding text and section.text. It is reccomended that documents do not duplicate the content in Composition.section.text with content in Composition.text. Proposed Wording: Comment: Is there any other guidance on this? The change log suggests that there will be guidance given so we were expecting further details than what we see (see Existing wording) Submitted by: Telus Health Row 19 |
Unresolved | Defer until we get more guidance from IPS for this topic |
| PS-100 | No explicit guidance on masking for individual items or resources. |
Summary: No explicit guidance on masking for individual items or resources.
Existing Wording: Proposed Wording: Comment: There is no explicit guidance on masking for individual items or resources. There is a section on Missing Data. Our assumption is that when data is masked, the Data Absent Reason is used to indicate masked data. Explicit guidance would be appreciated. Submitted by: Telus Health Row 20 |
Considered-Question answered | Guidance on Element or Resource masking is not in scope for PS-CA. Jurisdictional masking policies should be followed.
|
| PS-101 | The binding PregnanciesSummaryUvIps (required) appears to be missing LOINC code '11966-6' (Total number of times the patient has been pregnant including the present pregnancy). |
Summary: The binding PregnanciesSummaryUvIps (required) appears to be missing LOINC code '11966-6' (Total number of times the patient has been pregnant including the present pregnancy).
Existing Wording: Proposed Wording: Comment: The binding PregnanciesSummaryUvIps (required) appears to be missing LOINC code '11966-6' (Total number of times the patient has been pregnant including the present pregnancy). In one of our EMR's, this would map to form labels such as ‘Gravida’ and ‘Total Pregnancies’. Without this missing LOINC code, implementers may mistakenly map ‘Gravida’ and ‘Total Pregnancies’ to '11640-0' (Total number of births including abortions, stillbirths and live births. [Note: Because of multiple gestation this number may be greater than the number of abortions plus parity, the number of times the uterus is emptied of a viable pregnancy.) Submitted by: Telus Health Row 21 |
Unresolved | Raise with IPS to adopt extra code. Deferred. |
| PS-102 | BR3-19 needs clarification |
Summary: BR3-19 needs clarification
Existing Wording: BR3-19: PS-CA Solution SHALL ensure that access to clinical data is short-lived (e.g., expire after a certain time period or after a specific number of uses) to minimize unauthorized consumption. Proposed Wording: Comment: This technical requirement is extremely vague. It also seems similar to BR3-18 for SHLink, but BR3-19 is mapped to use cases UC-01 through UC-05. How would this requirement work for provider to provider exchange? For UC-02 for example, would the HCP only have access to the PS for a certain time period? Submitted by: Annie Ooi Epic Row 22 |
Persuasive | BR3-18 - Expiry of SHL (access link Validity)
BR3-19 - Session/Data Exposure Limit (Controlled access to a Patient Summary) Both requirements will be revised to clarify their differences, and BR3-19 will be mapped to UC-05. BR3-18 _The PS-CA Solution SHALL, where SHLink is supported, apply a default expiry date to the SHLink unless an alternative expiry date is specified by the patient or their designated caregiver._ BR3-19 _The PS-CA Solution SHALL, where SHLink is suported, limit access to the Patient Summary via an SHLink by enforcing that the data is short-lived (e.g., restricting the number of uses, setting a time-based expiry, or ending access after inactivity) to minimize unauthorized consumption._ |
| PS-103 | Clarify scope and create distinct document types as needed. |
Summary: Clarify scope and create distinct document types as needed.
Existing Wording: Proposed Wording: Clearly define the intended scope of the PS-CA document. If supporting multiple workflows is desired, consider creating a structured family of derived Composition profiles (e.g., PS-CA-Discharge, PS-CA-ImmunizationSummary) that: • Inherit from the PS-CA base (IPS-aligned) • Use appropriate Composition.type codes (e.g., LOINC) • Constrain required sections and content based on workflow • Support attestation or narrative expectations where clinically appropriate This will help maintain IPS compatibility while ensuring appropriate application to real-world workflows across Canadian jurisdictions. Comment: The specification lists several use cases but does not clearly constrain the scope of the PS-CA document to a defined workflow or clinical purpose. This leads to ambiguity about whether the profile is intended solely for general patient summaries or if it is also suitable for workflow-specific scenarios (e.g., discharge summary, referral, or an immunization-only summary from a jurisdictional registry). The inclusion of specialized use cases, like immunization-only summaries, which have been debated within the IPS community could diverge from the core goals of IPS and patient summary documents if not clearly separated by profile. Submitted by: Tony Waldschmidt Epic |
Considered-Question answered | The PS-CA is now fully aligned with the IPS regarding required data domains and will remain a comprehensive Patient Summary document. It is not intended for use in other workflows outside of the Patient Summary context. |
| PS-104 | Terminology- update recommended Pan-Canadian value set; AllergyIntoleranceClinicalStatusCodes |
Summary: update recommended Pan-Canadian value set
Existing Wording: Proposed Pan-Canadian value set is AllergyIntoleranceStatusCode (SNOMED CT-CA). Proposed Wording: AllergyIntoleranceClinicalStatusCodes* (HL7) Comment: AllergyIntolerance.clinicalStatus: CIHI is recommending AllergyIntoleranceClinicalStatusCodes (HL7) as the Pan-Canadian value set Submitted by: Joanie Harper CIHI |
Persuasive with Modification | Remove the slices that were used for additional bindings and revert to the required HL7 value set |
| PS-105 | update recommended Pan-Canadian value set: AllergyIntoleranceVerificationStatusCodes (HL7) |
Summary: update recommended Pan-Canadian value set
Existing Wording: Proposed Pan-Canadian value set is AllergyIntoleranceStatusCode (SNOMED CT-CA) Proposed Wording: AllergyIntoleranceVerificationStatusCodes (HL7) Comment: AllergyIntolerance.verificationStatus: CIHI is recommending AllergyIntoleranceVerificationStatusCodes (HL7) as the Pan-Canadian value set Submitted by: Joanie Harper CIHI |
Persuasive with Modification | Remove the slices that were used for additional bindings and revert to the required HL7 value set |
| PS-106 | update recommended Pan-Canadian value set: AllergyIntolerance.code: CIHI is recommending PharmaceuticalBiologic ProductAndSubstance Code as the Pan-Canadian value set, |
Summary: update recommended Pan-Canadian value set
Existing Wording: Proposed Pan-Canadian value set is SubstanceAndPharmaceuticalBiologicProductCode' (SNOMED CT-CA) Proposed Wording: PharmaceuticalBiologic ProductAndSubstance Code Comment: AllergyIntolerance.code: CIHI is recommending PharmaceuticalBiologic ProductAndSubstance Code as the Pan-Canadian value set, to align with with the Canadian Core Data for Interoperability (CACDI) v1 Submitted by: Marie-Chantal Ethier CIHI |
Persuasive | Update to the Recommended value set as a preferred binding |
| PS-107 | update recommended Pan-Canadian value set; Condition.Code-CIHI recommending HealthConditionCode as the Pan-Canadian value set. |
Summary: update recommended Pan-Canadian value set
Existing Wording: Proposed Pan-Canadian value set Is ClinicalFindingCode (SNOMED CT-CA) Proposed Wording: HealthConditionCode (SNOMED CT CA) Comment: Condition.code: As of the March 2025 CACDI publication, CIHI is now recommending HealthConditionCode as the Pan-Canadian value set. Submitted by: Joanie Harper CIHI |
Persuasive | update as requested |
| PS-108 | update recommended Pan-Canadian value set- Immunization.Site |
Summary: update recommended Pan-Canadian value set
Existing Wording: No Proposed Pan-Canadian value set Proposed Wording: ImmunizationAdministrationAnatomicalSiteCode (SNOMED CT CA) Comment: Immunization site: CIHI is recommending ImmunizationAdministrationAnatomicalSiteCode as the Pan-Canadian value set Submitted by: Joanie Harper CIHI |
Persuasive | Add the requested value set with a preferred binding |
| PS-109 | update recommended Pan-Canadian value sets- Medication code: CIHI recommends that CCDD value sets be used directly. |
Summary: update recommended Pan-Canadian value sets
Existing Wording: Proposed Pan-Canadian value set is PrescriptionMedicinalProduct Proposed Wording: CCDD - Manufactured Products - MP CCDD - Non Proprietary Therapeutic Products - NTP CCDD - Therapeutic Moiety - TM Comment: Medication code: CIHI is recommending that CCDD value sets be used directly. Note: The proposed value sets are the one listed on the new Terminology Server. Submitted by: Joanie Harper CIHI |
Not Persuasive | Existing Value Set is defined as codes from CCDD where ccddtype in MP,TM,NTP,DNTP; this is convenient, as opposed to binding four Value Sets. |
| PS-110 | add recommended Pan-Canadian value set alternates: Medication Code; Add 3 alternate value sets to the proposed Pan-Canadian value set |
Summary: add recommended Pan-Canadian value set alternates
Existing Wording: No Proposed Alternate value sets Proposed Wording: Add 3 alternate value sets to the proposed Pan-Canadian value set Comment: Medication code: CIHI has recommended HealthCanadaNaturalProductNumber, WhoAtcUvIps, and PharmaceuticalBiologicProductAndSubstanceCode as alternate Pan-Canadian value sets Submitted by: Joanie Harper CIHI |
Persuasive | PharmaceuticalBiologicProductAndSubstanceCode as alternate Pan-Canadian value set
The others are there already |
| PS-111 | update recommended Pan-Canadian value set: Medication form: CIHI is recommending PrescriptionDrugForm as the Pan-Canadian value set |
Summary: update recommended Pan-Canadian value set
Existing Wording: Proposed Pan-Canadian value set is PharmaceuticalDoseFormCode (SNOMED CT-CA) Proposed Wording: PrescriptionDrugForm (HL7) (SNOMED CT CA) Comment: Medication form: CIHI is recommending PrescriptionDrugForm as the Pan-Canadian value set Submitted by: Joanie Harper CIHI |
Persuasive | CIHI requested that their recommendation be placed on hold pending further research. |
| PS-112 | update recommended Pan-Canadian value set: Medication.ingredient: CIHI is recommending that CCDD value sets be used directly. |
Summary: update recommended Pan-Canadian value set
Existing Wording: Proposed Pan-Canadian value set is DrugOrMedicamentSubstanceCode Proposed Wording: CCDD - Therapeutic Moiety - TM Comment: Medication.ingredient: CIHI is recommending that CCDD value sets be used directly. Note: The proposed value set is the one listed on the new Terminology Server. DrugOrMedicamentSubstanceCode is recommended as an alternate value set. Submitted by: Joanie Harper CIHI |
Not Persuasive | Existing Value Set is defined as codes from CCDD where ccddtype in MP,TM,NTP,DNTP; this is convenient, as opposed to binding four Value Sets. |
| PS-113 | update recommended Pan-Canadian value sets; MedicationRequest.medicationCodeableConcept: CIHI is recommending that CCDD value sets be used directly. |
Summary: update recommended Pan-Canadian value sets
Existing Wording: Proposed Pan-Canadian value set is PrescriptionMedicinalProduct Proposed Wording: CCDD - Manufactured Products - MP CCDD - Non Proprietary Therapeutic Products - NTP CCDD - Therapeutic Moiety - TM Comment: MedicationRequest.medicationCodeableConcept: CIHI is recommending that CCDD value sets be used directly. Note: The proposed value sets are the one listed on the new Terminology Server. Submitted by: Joanie Harper CIHI |
Not Persuasive | Existing Value Set is defined as codes from CCDD where ccddtype in MP,TM,NTP,DNTP; this is convenient, as opposed to binding four Value Sets. |
| PS-114 | update recommended Pan-Canadian value sets: MedicationStatement.medicationCodeableConcept: CIHI is recommending that CCDD value sets be used directly. |
Summary: update recommended Pan-Canadian value sets
Existing Wording: Proposed Pan-Canadian value set is PrescriptionMedicinalProduct Proposed Wording: CCDD - Manufactured Products - MP CCDD - Non Proprietary Therapeutic Products - NTP CCDD - Therapeutic Moiety - TM Comment: MedicationStatement.medicationCodeableConcept: CIHI is recommending that CCDD value sets be used directly. Note: The proposed value sets are the one listed on the new Terminology Server. Submitted by: Joanie Harper CIHI |
Not Persuasive | Existing Value Set is defined as codes from CCDD where ccddtype in MP,TM,NTP,DNTP; this is convenient, as opposed to binding four Value Sets. |
| PS-115 | Advise what is projected for September 2025 publication. |
Summary: Advise what is projected for September 2025 publication.
Existing Wording: Proposed Wording: Comment: Procedure Code: CIHI has been working on Procedure as part of our publication for Sept 2025. We will be recommending Canadian Classification of Health Interventions (CCI) as an alternate Pan-Canadian value set but we still need to do the consultation work to validate this recommendation. Submitted by: Joanie Harper CIHI |
Persuasive | Add suggested note to procedure code |
| PS-116 | When clicking on a valueset, the page that opens is still indicating Terminology Gateway. |
Summary: When clicking on a valueset, the page that opens is still indicating Terminology Gateway.
Existing Wording: Proposed Wording: Comment: The value sets should be updated to reflect that value sets are now coming from the Terminology Server rather than the Terminology Gateway which is set to be retired at the end of April 2025. Submitted by: Joanie Harper CIHI |
Persuasive | Update Valueset Links |
| PS-117 | Improperly placed comment; PractitionerRoleLabPSCA.code |
Summary: Improperly placed comment
Existing Wording: Proposed Wording: Comment: Comment refers to work underway for .specialty Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive with Modification | Revert to R4 comment which states "A person may have more than one role." |
| PS-118 | Practitioners have specialties, not PractitionerRoles |
Summary: Practitioners have specialties, not PractitionerRoles
Existing Wording: Proposed Wording: Comment: Specialty is a characteristic of a practitioner, not a practitioner role. A Practitioner has a specialty (e.g. cardiology) and plays a PractitionerRole (e.g. cardiologist) for an organization. Submitted by: Marc L'Arrivee Shared Health (MB) |
Not Persuasive | No change. Speciality is defined by base FHIR. Practitioners have Qualifications (credentials), PractitionerRoles have Specialty. |
| PS-119 | Short Description does not decsribe this element: PractitionerRoleLabPSCA.code |
Summary: Short Description does not decsribe this element
Existing Wording: Concept - reference to a terminology or just text Proposed Wording: Code or text describing the practioner's role in the organization Comment: Short Description does not decsribe this element Submitted by: Marc L'Arrivee Shared Health (MB) |
Not Persuasive | No change. Speciality is defined by base FHIR. Practitioners have Qualifications (credentials), PractitionerRoles have Specialty. |
| PS-120 | Definition should not contain references to authorization; PractitionerRoleLabPSCA.code |
Summary: Definition should not contain references to authorization
Existing Wording: Roles which this practitioner is authorized to perform for the organization. Proposed Wording: Roles which this practitioner performs for the organization Comment: Definition should not contain references to authorization Submitted by: Marc L'Arrivee Shared Health (MB) |
Not Persuasive | This is from R4, no change. |
| PS-121 | Table has a heading of "Tables", change to "Glossary". |
Summary: Table has a heading of "Tables", change to "Glossary".
Existing Wording: Tables Proposed Wording: Glossary Comment: Table has a heading of "Tables", change to "Glossary". Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed, Title will be updated |
| PS-122 | Change column headings |
Summary: Change column headings
Existing Wording: Proposed Wording: Comment: Change column 1 heading from "Term" to "Term/Acronym" and column 2 heading to "Description" as these more accurately reflect the contents of these columns. Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed, Column Headings will be updated |
| PS-123 | Author for system generated patient summaries |
Summary: Glossary of Terms and Acronyms - PS-CA Author: Author for system generated patient summaries
Existing Wording: Proposed Wording: Comment: I believe systems can author/generate patient summaries, this entry should be updated to reflect that. Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive with Modification | We agree that the PS-CA Author can be either a human or a device. Since "Author" is already defined in the base FHIR specification and the PS-CA use cases do not explicitly model the Author as a distinct actor, we will remove "PS-CA Author" from the Glossary to avoid redundancy and potential confusion |
| PS-124 | Glossary of Terms and Acronyms - CA:FMT |
Summary: Glossary of Terms and Acronyms - CA:FMT
Existing Wording: ... that provides formatting support service Proposed Wording: ... that provides formatting support services Comment: ... that provides formatting support services Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed, Typo will be corrected |
| PS-125 | Glossary of Terms and Acronyms - CCDD- Statement too definitive/prescriptive |
Summary: Statement too definitive/prescriptive
Existing Wording: ...is the drug terminology for use... Proposed Wording: ...is a drug terminology available for use… Comment: Statement too definitive/prescriptive Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed, Typo will be corrected |
| PS-126 | Glossary - A Clinical Data Repository is not only for documents. |
Summary: A Clinical Data Repository is not only for documents.
Existing Wording: Proposed Wording: Comment: A Clinical Data Repository is not only for documents. Remove parenthetical i.e. and replace "clinical documents" with "clinical data". Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed. CDR definition will be updated to
A Clinical Data Repository is a shared storage space for clinical data that can be hosted locally (e.g., at the data producer) or at the Central Infrastructure and can be accessed by authorized users. |
| PS-127 | Glossary: Conformance Testing - Standards do not make any claims |
Summary: Glossary: Conformance Testing - Standards do not make any claims
Existing Wording: … to the stated parameters that are being claimed in the standard. Proposed Wording: ... to the requirements contained in the standard or specification. Comment: Standards do not make any claims Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive with Modification | Agreed. Definition will be updated
Conformance testing is a formal process of assessment focused on ensuring clinical solutions and systems accurately implement a particular specification (e.g. PS-CA). It ensures that the implementation aligns with the defined requirements and parameters outlined in the standard. |
| PS-128 | Glossary: PS-CA Consumer - Clinical data rather than clinical documents |
Summary: Glossary: PS-CA Consumer - Clinical data rather than clinical documents
Existing Wording: ...that enables access to or receipt of a clinical document Proposed Wording: ...that enables access to or receipt of clinical data Comment: Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed. Description will be updated
PS-CA Consumer - A health records system (e.g., EMR, HIS, CIS, PHR, Patient Portal, or EHR) that enables an authorized healthcare provider or the subject of care/patient to access, receive, and utilize a Patient Summary. |
| PS-129 | Glossary: DIN - Typo |
Summary: DIN - Typo
Existing Wording: A Drug Identification Number (DIN) is a computer-generated eight digit number assigned by Health Canada to a drug product prior to being marketed in Canada. Proposed Wording: A Drug Identification Number (DIN) is a computer-generated eight digit number assigned by Health Canada to a drug product prior to it being marketed in Canada. Comment: Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed. Typo will be corrected . |
| PS-130 | Properly define Document Repository |
Summary: Properly define Document Repository
Existing Wording: See Clinical Data Repository (Local or Central) Proposed Wording: Comment: Cannot just reference Clinical Data Repository, as a Clinical Data Repository may contain data other than documents. Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed. Definition will be updated.
A Document Repository is a shared storage space for documents, such as patient summaries, that can be hosted locally or at a central infrastructure and accessed by authorized users. |
| PS-131 | Glossary: PS-CA Producer - Include data, not just documents |
Summary: Include data, not just documents
Existing Wording: ...that creates/produces a clinical document… Proposed Wording: ...that creates/produces clinical data… Comment: Include data, not just documents Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed. Definition will be updated
_A health records system (e.g., EMR, HIS, CIS, PHR, or EHR) that creates/produces clinical data (e.g., PS-CA) in response to a request from an authorized health care provider, the subject of care, or another authorized health records system._ |
| PS-132 | Glossary: PS-CA Specifications - Replace placeholder with actual link |
Summary: Replace placeholder with actual link
Existing Wording: (Source: PS-CA Specifications Link) Proposed Wording: Comment: I believe this is a placeholder, replace with actual link. Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed, the updated source link will be added to the definition. |
| PS-133 | Glossary: Shareable Health Link (SHL, SHLink) |
Summary: Shareable Health Link (SHL, SHLink)
Existing Wording: SHL is based on HL7 SMART Health Links and generally can be used interchangeably. Proposed Wording: SHL is based on HL7 SMART Health Links and generally the two can interoperate. Comment: Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive with Modification | The definition will be updated, and a link to HL7 Smart Health Links will be included. |
| PS-134 | Requirements: BR1-06 - Provide privacy warning on data extraction/saving |
Summary: Provide privacy warning on data extraction/saving
Existing Wording: Proposed Wording: Comment: Related to BR1-06, should a PS-CA solution provide a privacy warning to the user on an attempt to extract or save data? Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Whether a PS-CA solution should display a privacy warning when a user attempts to extract or save data related to BR1-06 depends on design and implementation choices, as well as jurisdictional policies.
A note will be added to BR1-06 for implementers to follow applicable jurisdictional privacy and security policies when supporting data extraction, download, or storage. |
| PS-135 | Requirements: BR1-07 should be guidance, not requirement |
Summary: BR1-07 should be guidance, not requirement
Existing Wording: A PS-CA Author SHOULD reasonably ensure that the health information contained in a Patient Summary-CA is accurate, sufficiently complete and up to date to meet the specified clinical purpose. Proposed Wording: Comment: BR1-07 speaks to the behaviour of a PS-CA Author. I think, as a requirement, this goes beyond what should be done here. It would be fine to have this as guidance somewhere in the spec, but not as a requirement. Submitted by: Marc L'Arrivee Shared Health (MB) |
Not Persuasive | Some requirements are intended to guide and support stakeholders in their implementation of PS-CA. For example, certain requirements may reference to local/jurisdictional policies and/or standards, indicating that implementers should validate specific requirement needs, if any, within a jurisdiction.
Including this “SHOULD” statement in the requirements section balances promoting a clinical quality expectation with providing practical flexibility. It ensures that data quality remains a clear, explicit priority guiding system design and implementation without imposing unrealistic conformance demands. |
| PS-136 | Requirements: Use phrase "in accordance with" |
Summary: Use phrase "in accordance with"
Existing Wording: Proposed Wording: Comment: The phrase "in accordance to" is used in various places; this phrase should be "in accordance with". Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed. Correction will be made. |
| PS-137 | Requirements: BR1-11 - Clarify how a PS-CA Solution should limit sharing of health information |
Summary: Clarify how a PS-CA Solution should limit sharing of health information
Existing Wording: A Patient Summary-CA Solution SHOULD limit the sharing of health information to what is clinically necessary and sufficient, in accordance with governing legislation and the Patient Summary-CA specification. Proposed Wording: A Patient Summary-CA Solution SHOULD allow the limiting of the health information shared to what is clinically necessary and sufficient, in accordance with governing legislation and the Patient Summary-CA specification. Comment: Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive with Modification | The PS-CA Solution limits sharing by including only the data elements defined in the PS-CA specification (system rules). It filters out non-essential data and ensures compliance with relevant legislation and consent requirements.
The requirement will be updated for clarity. A Patient Summary-CA Solution SHOULD enable limiting the sharing of health information to what is clinically necessary and sufficient, in accordance with governing legislation and the Patient Summary-CA specification. |
| PS-138 | Requirements : BR1-13 Extend access to patient summary |
Summary: Extend access to patient summary
Existing Wording: Proposed Wording: Comment: Related to BR1-13, the capability to access a patient summary should extend to an authorized caregiver, legal decision maker, parent/guardian, etc. Also what about generating a patient summary (triggered by the patient, caregiver, etc.)? Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | BR1-13 will be updated, and a new requirement BR1-16 for generation will be added.
BR1-13 - A Patient Summary-CA Solution SHOULD provide the Patient/Subject of Care, or their authorized representative (e.g., caregiver, legal decision-maker), access to their Patient Summary in accordance with jurisdictional policies and legislative provisions. BR1-16 - A Patient Summary-CA Solution SHOULD support the ability for a patient or their authorized representative (e.g., caregiver, legal decision-maker) to request or trigger the creation of a Patient Summary, in accordance with jurisdictional policies and legislative provisions. |
| PS-139 | Review requirements in context of patient-generated patient summaries. |
Summary: Review requirements in context of patient-generated patient summaries.
Existing Wording: Proposed Wording: Comment: Requirements should be reviewed in the context of patient-triggered generation of a patient summary. Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | A new requirement will be added to support patient-generated PS.
_BR1-16 - A Patient Summary-CA Solution SHOULD support the ability for a patient or their authorized representative (e.g., caregiver, legal decision-maker) to request or trigger the creation of a Patient Summary, in accordance with jurisdictional policies and legislative provisions._ |
| PS-140 | Requirements: BR3-03 Patient Summary sending |
Summary: Patient Summary sending
Existing Wording: Patient Summary-CA Solution SHALL provide the ability to send a Patient Summary by identifying a recipient health care provider (e.g., virtual submission to a clinic identified via registry lookup). Proposed Wording: Comment: This is getting into eReferral territory. Further it seems like more of a business requirement. Submitted by: Marc L'arrive Shared Health (MB) |
Considered for Future Use | This requirement focuses on system functionality rather than a specific business need. That said, there are valid reasons for Patient Summary exchanges between providers.
Since the use case is still under development, the requirement is currently in draft status and will be reevaluated as the use case progresses. |
| PS-141 | Requirements: BR3-06 Local/jurisdictional and industry standards for authentication |
Summary: Local/jurisdictional and industry standards for authentication
Existing Wording: Patient Summary-CA Solution SHOULD adhere to minimum local/jurisdictional industry standards for authentication (e.g., multi-factor authentication) of authorized users. Proposed Wording: Patient Summary-CA Solution SHOULD adhere to minimum local/jurisdictional and industry standards for authentication (e.g., multi-factor authentication) of authorized users. Comment: Need to adhere to minimum local/jurisdictional and industry standards. Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Correction will be made. |
| PS-142 | Requirements: BR3-07 Extra space after comma |
Summary: Extra space after comma
Existing Wording: Patient Summary-CA solution SHOULD , where feasible Proposed Wording: Patient Summary-CA solution SHOULD, where feasible Comment: Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Correction will be made. |
| PS-143 | Requirements: BR3-08 Protection of health information in transit is beyond the scope of a PS-CA |
Summary: Protection of health information in transit is beyond the scope of a PS-CA
Existing Wording: Patient Summary-CA Solution SHOULD protect health information in transit, adhering to jurisdictional standards for encryption. Proposed Wording: Patient Summary-CA Solution SHOULD adhere to jurisdictional standards for encryption. Comment: Protection of health information in transit is beyond the scope of a PS-CA. The best a PS-CA can do is encrypt the data before sending it. Submitted by: Marc L'Arrivee Shared Health (MB) |
Not Persuasive with Modification | This requirement provides guidance on security expectations for handling Patient Summaries.
The wording of the requirement will be updated for clarity. A Patient Summary-CA Solution should protect health information in transit using secure channels (e.g., HTTPS) and comply with jurisdictional standards for data encryption.{_}.{_} |
| PS-144 | Relationship between BR3-07 and BR3-09 |
Summary: Relationship between BR3-07 and BR3-09
Existing Wording: Proposed Wording: Comment: What is the relationship, if any between BR3-07 and BR3-09? BR3-07 seems more like advice to a jurisdiction rather than a technical requirement. Submitted by: Marc L'Arrivee Shared Health (MB) |
Considered-Question answered | BR3-07 and BR3-09 both address security controls around access to the Patient Summary, but focus on different perspectives and levels of detail.
BR3-07 provides high-level guidance for jurisdictions to segregate duties and prevent unauthorized PHI access, serving as a policy recommendation. BR3-09 details the technical implementation of this guidance through role-based access control (RBAC) and industry standards. Essentially, BR3-07 explains why segregation is needed, while BR3-09 describes how to implement it. |
| PS-145 | Requirements: Increase obligation of BR3-16 |
Summary: Increase obligation of BR3-16
Existing Wording: Patient Summary-CA Solution SHOULD create the PS-CA in a structured format that aligns with the FHIR version identified in the PS-CA IG Proposed Wording: Patient Summary-CA Solution SHALL create the PS-CA in a structured format that aligns with the FHIR version identified in the PS-CA IG Comment: Shouldn't this be a SHALL? Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed. This is a Mandatory Requirement |
| PS-146 | BR3-17 is too broad |
Summary: BR3-17 is too broad
Existing Wording: Patient Summary-CA Solution SHOULD protect health information at rest, adhering to jurisdictional standards for encryption. Proposed Wording: Patient Summary-CA Solution SHOULD protect health information at rest stored or generated by it, adhering to jurisdictional standards for encryption. Comment: Protection of health information at rest in general is beyond the scope of a PS-CA Submitted by: Marc L'Arrivee Shared Health (MB) |
Not Persuasive | While full protection of all health data at rest may be out of scope, this is a guidance-level requirement aimed at ensuring that any Patient Summary data the PS-CA solution stores or generates is protected even temporarily. |
| PS-147 | Requirements:BR3-18 is conditional on support for SHLinks |
Summary: BR3-18 is conditional on support for SHLinks
Existing Wording: PS-CA Solution SHALL have a default expiry date for the SHLink if not changed by the Patient (or designated caregiver). Proposed Wording: Comment: Somewhat of a conditional requirement, as I did not see any requirement to support SHLinks. Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed. The requirement will be updated.
The PS-CA Solution SHALL, where SHLink is supported, apply a default expiry date to the SHLink unless the Patient or their designated caregiver specifies an alternative expiry date{_}.{_} |
| PS-148 | BR3-19 is not specific enough and seems to be related to links |
Summary: BR3-19 is not specific enough and seems to be related to links
Existing Wording: PS-CA Solution SHALL ensure that access to clinical data is short-lived (e.g., expire after a certain time period or after a specific number of uses) to minimize unauthorized consumption. Proposed Wording: Comment: Requirement is not specific enough. How long is short-lived? Should this be configurable? This seems related to links. Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive with Modification | This requirement supports SHLinks. The allowed duration or number of times an SHLink can be used to access a Patient Summary will vary based on the implementation and applicable jurisdictional policies.
BR3-19 will be updated for clarity. The PS-CA Solution SHALL, where SHLink is supported, limit access to the Patient Summary via an SHLink by enforcing that the data is short-lived (e.g., restricting the number of uses, setting a time-based expiry, or ending access after inactivity) to minimize unauthorized consumption. |
| PS-149 | Requirements: BR3-20 is conditional on support for SHLinks |
Summary: BR3-20 is conditional on support for SHLinks
Existing Wording: PS-CA Solution SHALL provide safeguards (e.g., passcode) for the PS-CA Producer to prevent the SHLink from being accessed by the wrong party Proposed Wording: Comment: Somewhat of a conditional requirement, as I did not see any requirement to support SHLinks. Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | This requirement supports SHLinks and will be updated for clarity.
PS-CA Solution SHALL, where SHLink is supported, provide safeguards (e.g., passcode) for the PS-CA Producer to prevent the SHLink from being accessed by the wrong party |
| PS-150 | UC:Technical Requirement Mapping - Typo |
Summary: Typo: Technically
Existing Wording: Use Case and Technically Requirement Mapping Proposed Wording: Use Case and Technical Requirement Mapping Comment: Typo: Technically Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Typo will be corrected |
| PS-151 | There's a mismatch between how the 'Patient Summary CA Solution' is described in the Business Requirements and how it's shown in the Use Case diagrams. |
Summary: There's a mismatch between how the 'Patient Summary CA Solution' is described in the Business Requirements and how it's shown in the Use Case diagrams.
Existing Wording: Proposed Wording: Comment: On the Business Context-Requirements page, the business rules all are written to apply to a single Actor of 'Patient-Summary CA Solution'. In reading this, the logical conclusion is that 'Solution' refers to all components of an integrated end-to-end view - encompassing the sending/authoring system, the consuming/receiving system and perhaps anything in between. But then reading through the Use Cases page, the diagrams all show 'Patient Summary CA Solution' as a system separate from both sending and receiving systems. So this discrepancy could make it confusing for vendors to figure out what does or doesn't apply to their products based on the product's role in the end-to-end flow. Submitted by: Sandra Lambert Infoway |
Persuasive | The observation is valid. We define the PS-CA solution as a combination of systems that could be comprised of various Producer and Consumer systems. However, in our UC diagrams, we present the PS-CA solution as a single actor separate from the consumer or producer systems. We need to review all sequence diagrams and UCs and update them. Due to the scope of the work, this update will be deferred to a future release, as it cannot be completed in time for the v2.1.0 DFT release. |
| PS-152 | There’s significant text around the use of IDMP levels, which aren’t used in Canada. |
Summary: There’s significant text around the use of IDMP levels, which aren’t used in Canada.
Existing Wording: Proposed Wording: Comment: There’s significant text around the use of IDMP levels, which aren’t used in Canada. SNOMED is currently mapping to IDMP as well. Suggest all the content around IDMP be removed if it is not applicable, as it may confuse or overwhelm readers/implementers. They were included in PS-CA because the IPS mentions them all (https://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Immunization-uv-ips-definitions.html#key_Immunization.vaccineCode) – but IPS has no included any bindings to them to date. Submitted by: Linda Parisien Myriam Talantikit Infoway |
Persuasive | Remove content around IDMP |
| PS-153 | The four ValueSet IG pages for the VaccineCode bindings currently point to the TGateway, rather than the TermServer. |
Summary: The four ValueSet IG pages for the VaccineCode bindings currently point to the TGateway, rather than the TermServer.
Existing Wording: Proposed Wording: Comment: The four ValueSet IG pages for the VaccineCode bindings (VaccineAdministeredTradeNameCode, VaccineHistoricalNameCode, PassiveAdministeredImmunizingAgentCode, PassiveHistoricImmunizingAgentCode) currently point to the TGateway, rather than the TermServer. Submitted by: Linda Parisien Myriam Talantikit Infoway |
Persuasive | ValueSet Links will be updated |
| PS-154 | Glossary: Shareable Health Link (SHL, SHLink) |
Summary: Shareable Health Link (SHL, SHLink)
Existing Wording: SHL is based on HL7 SMART Health Links and generally can be used interchangeably. Proposed Wording: SHL is based on HL7 SMART Health Links and generally the two can interoperate. Comment: Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive with Modification | Description will be updated.
_A secure, standardized link that enables patients to share their clinical health information (e.g., patient summaries) with healthcare providers. SHLs can be shared via QR codes or other secure electronic methods (e.g., email). SHLs are designed to facilitate the smooth exchange of health data, allowing information to travel with patients wherever they might be, supporting the continuity of care. SHL is based on [HL7 SMART Health Links|https://build.fhir.org/ig/HL7/smart-health-cards-and-links/links-specification.html]._ |
| PS-161 | Move Use Cases before Requirements |
Summary: Move Use Cases before Requirements
Existing Wording: Proposed Wording: Comment: Use Cases should be moved before requirements as the Requirements section references them. Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed, content will be restructured |
| PS-162 | UC - Patient-triggered generation |
Summary: Patient-triggered generation
Existing Wording: Proposed Wording: Comment: Is this spec covering the case of patient-triggered generation of a Patient Summary? Submitted by: Marc L'Arrivee Shared Health (MB) |
Considered-Question answered | Yes, Use Case 5 describes patient-mediated access and exchange of their Patient Summary. The pan-Canadian FHIR exchange specification describes transactions required for Patient-triggered generation. |
| PS-174 | UC-01 Index Description- Incomplete sentence |
Summary: Incomplete sentence
Existing Wording: To ensure that the most current patient information is available to other HCPs who may provide care in the future, supporting continuity of care and informed clinical decision-making. Proposed Wording: Comment: This is not a complete sentence. What it supposed to be a clause for the first or third sentence? Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed. UC-01 Index description will be updated for clarity
A Health Care Provider in any care setting creates a Patient Summary for use at the point of care, which is made available to Patient Summary consumers. This ensures that the most current patient information is available to other HCPs who may provide care in the future, supporting continuity of care and informed clinical decision-making. It also provides the ability for a HCP to share the most current information about their patient in their health records system (e.g., EMR) to a central location, where other authorized health care providers can access the patient summary. |
| PS-175 | UC-02 Index Description- Delete example or use better example |
Summary: Delete example or use better example
Existing Wording: (e.g., PDF document) Proposed Wording: Comment: Suggest not using a PDF example here. Rather say, "e.g. a FHIR Document that has been rendered." Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed. The example will be updated to "rendered FHIR Document." |
| PS-176 | UC-05 Index Description - Encrypted QR code |
Summary: Encryped QR code
Existing Wording: ...the patient provides access to their patient summary via the encrypted QR code… Proposed Wording: Comment: Is it the QR Code that is encrypted? Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | UC-05 index description will be updated to clarify that the Patient summary is encrypted.
A patient, via a patient-facing application, requests access to a shareable copy of their patient summary. Subsequently, the patient provides access to their encrypted patient summary via QR code on their mobile device or by sharing a secure shareable health link (e.g., via email) at the point of care (e.g., walk-in clinic, emergency department). The Health Care Provider scans the QR code or accesses the shareable health link shared by the patient, addressing any security prompts, such as entering a passcode if required, and then may proceed to view/utilize and consume the patient summary. |
| PS-177 | UC-05 Index - Redundant sentence |
Summary: Redundant sentence
Existing Wording: Provides the ability for a patient to request access to their Patient Summary for sharing with a health care provider using a QR code. Proposed Wording: Comment: Delete. This last sentence is unnecessary/redundant. Also doesn't address the shareable link option. Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Agreed, will remove redundant statement. |
| PS-178 | Displaying of data type information rather than Element information |
Summary: Displaying of data type information rather than Element information
Existing Wording: Proposed Wording: Comment: Many elements are displaying a data type definition rather than their element definition (or displaying a definition under 'Binding'). One example is FamilyMemberHistoryPSCA.relationship Submitted by: Marc L'Arrivee Shared Health (MB) |
Persuasive | Display bug. Ticket opened with firely |
| PS-179 | FamilyMemberHistoryPSCA- Include privacy guidance |
Summary: Include privacy guidance
Existing Wording: Proposed Wording: Comment: Include guidance on privacy. For example, it’s one thing to say “family hx of breast cancer”, but another to say “mom – hx of breast cancer, sister – hx of breast cancer…”. This consideration should also influence the 'relationship' value set. Submitted by: Marc L'Arrivee Shared Health (MB) |
Not Persuasive | The PS-CA includes overaching privacy guidance for sharing personal health information within the "Privacy as an Enabler: Sharing Personal Health Informationi for Interoperability Primer."
This document is found in the PS-CA Implementation Guide's Business Context Menu: "Privacy and Security Guidance". As health-related privacy legislation varies across the country, it is critical that each jurisdiction implementing the PS-CA understand which laws apply within their jurisdiction. For example, the collection, use and disclosure of PHI by a physician or other health care provider is governed by the jurisdiciton's health privacy legislation, if one exists. |
| PS-183 | In Canada, we have developed vaccine concepts that would not be available from any of the IPS Vaccine Code, not the WHO ATC |
Summary: In Canada, we have developed vaccine concepts that would not be available from any of the IPS Vaccine Code, not the WHO ATC
Existing Wording: IPS Vaccine Code VaccinesUvIps - WHO ATC WhoAtcUvIps Proposed Wording: delete Comment: In Canada, we have developed vaccine concepts that would not be available from any of the IPS Vaccine Code, not the WHO ATC. Providing these bindings, means that only partial information on vaccine could be captured.If we decide to still keep these above bindings in the PS-CA, a Note to that effect should be provided. Submitted by: Linda Parisien Canada Health Infoway |
Not Persuasive with Modification | Keep the bindings and add a note highlighting that the WHO ATC WhoAtcUvIps does not provide coverage for all vaccines used in Canada. |
| PS-184 | ImmunizationPSCA Addition: current existing valueset for anatomical site codes |
Summary: Addition: current existing valueset for anatomical site codes
Existing Wording: Proposed Wording: Added preferred binding of ImmunizationAdministrationAnatomicalSiteCode Comment: Addition: current existing valueset for anatomical site codes Submitted by: Myriam Talantikit Canada Health Infoway |
Persuasive with Modification | Add ImmunizationAdministrationAnatomicalSiteCode as preferred binding |
| PS-185 | ImmunizationPSCA- Suggestion to delete all this paragraph as it is not relevant anymore |
Summary: Suggestion to delete all this paragraph as it is not relevant anymore
Existing Wording: The development of a FHIR ValueSet & Terminology Gateway subset for this element is underway. Given that the migration of terminology from the CVC to NVC is underway, and that this element is no longer MS in PS-CA or IPS, the profiling on this binding has been temporarily removed and will be re-applied in future updates once there is an established subset to point to. Proposed Wording: delete Comment: Suggestion to delete all this paragraph as it is not relevant anymore Submitted by: Myriam Talantikit Canada Health Infoway |
Persuasive | Agreed, the identified text will be removed from the site element. |
| PS-186 | ImmunizationPSCA- Infoway valuesets for different scope for Route of administration. |
Summary: Infoway valuesets for different scope for Route of administration.
Existing Wording: EDQM route of administration MedicineRouteOfAdministrationUvIps, HL7 v3 route of administration v3.RouteOfAdministration Proposed Wording: delete Comment: Infoway has developed multiple valuesets for different scope for Route of administration. The only binding should be the preferred one above. EDQM is not in use in Canada per say, SNOMED CT CA is aligned with EDQM. Submitted by: Linda Parisien Canada Health Infoway |
Not Persuasive with Modification | Keep the additional bindings, but add a note:
" While this additional binding is not primarily used in the Canadian healthcare context, it is retained to support potential use of PS-CA internationally and IPS within Canada. Implementers should be aware that this binding may not comprehensively represent all Canadian route of administration codes" |
| PS-187 | ImmunizationPSCA-Suggestion to remove paragraph as IPS not used in Canada |
Summary: Suggestion to remove paragraph as IPS not used in Canada
Existing Wording: Other differences between the IPS and PS-CA Include: Data type profiles (e.g., CodeableConcept) and reference targets (e.g., Patient) replaced with PS-CA equivalents when appropriate Immunization.vaccineCode: IPS datatype profiling removed Proposed Wording: delete Comment: Suggestion to remove this paragraph as IPS not used in Canada Submitted by: Myriam Talantikit Canada Health Infoway |
Persuasive | As discussed in several other tickets, we are retaining the section on the differences between IPS and PSCA as we may see IPS instances in Canada |
| PS-188 | Immunization-VaccineCode: Suggest to remove this text as in CA we are not using the IPS-UV vaccine concepts, because that would be a partial set of codes. No Canadian Trade names or Brand names would be available from that set of codes |
Summary: Suggest to remove this text as in CA we are not using the IPS-UV vaccine concepts, because that would be a partial set of codes. No Canadian Trade names or Brand names would be available from that set of codes
Existing Wording: IPS-UV Note: Several kinds of vaccine product coding could be provided. The IPS assumes that either the type of the vaccine for particular disease or diseases (e.g. MMR vaccine) against which the patient has been immunised is provided; or the known absent/unknown code. Other coded information can be provided as well as: the Pharmaceutical and medicinal product identifiers, when available, or equivalent coded concepts; the WHO ATC codes; or any other kind of code that that identifies, classifies or cluster the administered product. Proposed Wording: delete Comment: Suggest to remove this text as in CA we are not using the IPS-UV vaccine concepts, because that would be a partial set of codes. No Canadian Trade names or Brand names would be available from that set of codes. I would add here the note on the 4 Infoway valuesets that should be used in CA: Note: VaccineHistoricalNameCode, PassiveAdministeredImmunizingAgentCode, and PassiveHistoricalImmunizingAgentCode equivalently preferred to the primary binding as they convey codes that are intended to be utilized in different contexts (e.g., passive agents) Submitted by: Linda Parisien Canada Health Infoway |
Not Persuasive with Modification | Keep the IPS text and add:
_The IPS-UV vaccine concepts are not used in Canadian implementations as they do not include Canadian trade or brand names. Implementers should use the following pan-Canadian value sets, depending on context: "VaccineHistoricalNameCode", "PassiveAdministeredImmunizingAgentCode", and "PassiveHistoricalImmunizingAgentCode", which are equivalently preferred alongside the primary binding._ |
| PS-189 | Immunization-VaccineCode: Suggest removing these additional bindings as mentioned below |
Summary: Suggest removing these additional bindings as mentioned below
Existing Wording: Comments See additionalBinding extension. Future releases of PS-CA may require use of coded entries. In this release, however, implementations that support codings are encouraged to send the codings for codeable concepts if they are available. Consistent with FHIR best practice, receivers should not produce failures or rejections if codings are received. Vendors should expect that some jurisdictions may further constrain support of this element within the context of their own jurisdictional content. IPS-UV Note: Several kinds of vaccine product coding could be provided. The IPS assumes that either the type of the vaccine for particular disease or diseases (e.g. MMR vaccine) against which the patient has been immunized is provided; or the known absent/unknown. Other coded information can be provided as well as: 1. The IDMP Pharmaceutical Product Identifier (PhPID), Level 1, [Substance(s)]. Example: Amoxicillin and Clavulanate Potassium; or any other equivalent coded concept. 2. The IDMP Pharmaceutical Product Identifier (PhPID), Level 2 [Substance(s) + Strength + reference strength]. Example: Amoxicillin 875 mg and Clavulanate Potassium 125 mg; or any other equivalent coded concept. 3. The IDMP Pharmaceutical Product Identifier (PhPID), Level 3 [Substance(s) + administrable dose form]. Example: Amoxicillin and Clavulanate Potassium, Oral Tablet; or any other equivalent coded concept. 4. The IDMP Pharmaceutical Product Identifier (PhPID), Level 4 [Substance(s) + strength + reference strength + administrable dose form]. Example: Amoxicillin 875 mg and clavulanate potassium 125 mg, oral tablet; or any other equivalent coded concept. 5. The IDMP Medicinal Product Identifier (MPID) or any equivalent Medicinal Product Identifier. IDMP MPID uniquely identifies a Medicinal Product, reflecting (but not replacing) any other authorization numbers allocated by a regulator. MPID implies one (set of) PhPID. The MPID shall use a common segment pattern related to a Medicinal Product, which, when each segment is valued shall define a specific MPID concept. 6. The IDMP Packaged Medicinal Product Identifier (PCID) or any equivalent Packaged Medicinal Product Identifier. Uniquely identifies a Medicinal Product based on its packaging. This implies one MPID can be associated with more than one PCID, if the same Medicinal Product has more than one type of package. 7. Any other kind of code that that identifies, classifies or clusters the administered product (e.g. the medicinal product or the product class). The value sets used for the PhPID, MPID and PCID identifiers are provisional and include only few equivalent concepts used for exemplification purposes, they will be updated with real IDMP identifiers when they will become available. Proposed Wording: delete Comment: Suggest removing these additional bindings as mentioned below Submitted by: Myriam Talantikit Canada Health Infoway |
Not Persuasive | The set of bindings should remain. The removal of the IDMP text is covered by ticket PS-152 |
| PS-190 | Immunization-VaccineCode: Add valueset current definition |
Summary: Add valueset current definition
Existing Wording: VaccineHistoricalNameCode (preferred) Equivalently recommended for use when conveying vaccine generic names for scenarios when brand names…. Proposed Wording: VaccineHistoricalNameCode (preferred) This refset is intended to capture the immunization history and includes concepts represented by a generic description for a vaccine that was previously administered to the client Comment: Add valueset current definition and remove the old paragraph Submitted by: Myriam Talantikit Canada Health Infoway |
Persuasive | Agreed, text description will be updated as proposed
VaccineHistoricalNameCode (preferred) _This refset is intended to capture the immunization history and includes concepts represented by a generic description for a vaccine that was previously administered to the client_ |
| PS-191 | Immunization-VaccineCode: Add valueset current definition |
Summary: Add valueset current definition
Existing Wording: PassiveAdministeredImmunizingAgentCode (preferred) Equivalently recommended for use when conveying when passive immunization products are used. Proposed Wording: PassiveAdministeredImmunizingAgentCode (preferred) This refset is intended to capture the product administered at the point of immunization and includes the passive immunizing agent tradenames that are currently licensed for use in Canada, those obtained through special access programs for use in Canada, and those that were never licensed in Canada. Comment: Add valueset current definition and remove the old paragraph Submitted by: Myriam Talantikit Canada Health Infoway |
Persuasive | Agreed, text description will be updated as proposed
PassiveAdministeredImmunizingAgentCode (preferred) _This refset is intended to capture the product administered at the point of immunization and includes the passive immunizing agent tradenames that are currently licensed for use in Canada, those obtained through special access programs for use in Canada, and those that were never licensed in Canada._ |
| PS-192 | Immunization-VaccineCode: Add valueset current definition |
Summary: Add valueset current definition
Existing Wording: PassiveHistoricalImmunizingAgentCode (preferred) Equivalently recommended for use when conveying when passive immunization products are used. Proposed Wording: PassiveHistoricalImmunizingAgentCode (preferred) This refset is intended to capture the immunization history and includes concepts represented by a generic description for a passive immunizing agent that was previously administered to the client Comment: Add valueset current definition and remove the old paragraph Submitted by: Myriam Talantikit Canada Health Infoway |
Persuasive | Agreed, text description will be updated as proposed
PassiveHistoricalImmunizingAgentCode (preferred) _This refset is intended to capture the immunization history and includes concepts represented by a generic description for a passive immunizing agent that was previously administered to the client_ |
| PS-193 | Immunization-VaccineCode -Suggestion to remove as not relevant for Canada |
Summary: Suggestion to remove as not relevant for Canada
Existing Wording: VaccinesUvIps (candidate) IPS Vaccine codes value set. This value set includes codes from SNOMED CT. WhoAtcUvIps (candidate) Code that is selected from the WHO ATC classification. Proposed Wording: delete Comment: Suggestion to remove as not relevant for Canada Submitted by: Myriam Talantikit Canada Health Infoway |
Not Persuasive with Modification | Keep text and add note that:
* Acknowledges the binding's limited use in Canada * Explains the rationale for keeping it |
| PS-194 | Immunization.site: Remove "just text" as we have a current valueset |
Summary{*}:{*} Remove "just text" as we have a current valueset
Existing Wording: Short description Concept - reference to a terminology or just text Definition A concept that may be defined by a formal reference to a terminology or ontology. or may be provided by text. Proposed Wording: Short description Concept - reference to a terminology Definition A concept that may be defined by a formal reference to a terminology or ontology. Comment: Remove "just text" as we have a current valueset Submitted by: Myriam Talantikit Canada Health Infoway |
Not Persuasive | The referenced phrase is the definition of a CodeableConcept from the base FHIR specification
Further, we have the following comment: _Future releases of PS-CA may require use of coded entries. In this release, however, implementations that support codings are encouraged to send the codings for codeable concepts if they are available. Consistent with FHIR best practice, receivers should not produce failures or rejections if codings are received._ This should address the needed to encourage coded entries where possible |
| PS-195 | Immunization-site: Not relevant anymore, suggest to remove |
Summary: Not relevant anymore, suggest to remove
Existing Wording: Comments The development of a FHIR ValueSet & Terminology Gateway subset for this element is underway. Given that the migration of terminology from the CVC to NVC is underway, and that this element is no longer MS in PS-CA or IPS, the profiling on this binding has been temporarily removed and will be reapplied in future updates once there is an established subset to point to. Proposed Wording: delete Comment: Not relevant anymore, suggest to remove Submitted by: Myriam Talantikit Canada Health Infoway |
Persuasive | Agreed, the text will be removed |
| PS-196 | Immunization-site: Changed for the current valueset definition |
Summary: Changed for the current valueset definition
Existing Wording: Binding The site at which the vaccine was administered. Proposed Wording: Binding The anatomical site where the immunizing agent was administered. CodesForImmunizationSiteOfAdministration (example)ImmunizationAdministeredAnatomicalSiteCode Comment: Changed for the current valueset definition Submitted by: Myriam Talantikit Canada Health Infoway |
Persuasive | Agreed. Update definition |
| PS-197 | Immunization.site-Suggest to remove text |
Summary: Suggest to remove text
Existing Wording: Constraints • ele-1: All FHIR elements must have a @value or children hasValue() or (children().count() > id.count()) Mappings • v2: RXR-2 • rim: observation.targetSiteCode • cda: ClinicalDocument/component/StructuredBody/component/section/entry/substanceAdministration/approachSiteCode/code • rim: n/a • v2: CE/CNE/CWE • rim: CD • orim: fhir:CodeableConcept rdfs:subClassOf dt:CD Proposed Wording: delete Comment: Suggest to remove Submitted by: Linda Parisien Canada Health Infoway |
Not Persuasive | These are part of the technical requirements of FHIR and need to remain |
| PS-198 | Remove "just text" as we have a current valueset |
Summary: Remove "just text" as we have a current valueset
Existing Wording: Short description Concept - reference to a terminology or just text Definition A concept that may be defined by a formal reference to a terminology or ontology. or may be provided by text. Proposed Wording: Short description Concept - reference to a terminology Definition A concept that may be defined by a formal reference to a terminology or ontology. Comment: Remove "just text" as we have a current valueset Submitted by: Myriam Talantikit Canada Health Infoway |
Not Persuasive | Duplicate of PS-194, which was found Not Persuasive with the following comment:
The referenced phrase is the definition of a CodeableConcept from the base FHIR specification Further, we have the following comment: _Future releases of PS-CA may require use of coded entries. In this release, however, implementations that support codings are encouraged to send the codings for codeable concepts if they are available. Consistent with FHIR best practice, receivers should not produce failures or rejections if codings are received._ This should address the needed to encourage coded entries where possible |
| PS-199 | Immunization-route: Suggest to remove |
Summary: Suggest to remove
Existing Wording: Comments See additionalBinding extension. IPS-UV no longer flags this as a Must Support element. It is not currently flagged as Must Support in PS-CA, as stakeholders have indicated the element may not be supported by the majority of systems today. Systems that do support the element are encouraged to include it in generated Patient Summary documents, and support it when received. Proposed Wording: Comments See additionalBinding extension. Comment: Suggest to remove Submitted by: Linda Parisien Canada Health Infoway |
Persuasive | This is the comment for route - remove the two indicated paragraphs:
IPS-UV no longer flags this as a Must Support element. It is not currently flagged as Must Support in PS-CA, as stakeholders have indicated the element may not be supported by the majority of systems today. Systems that do support the element are encouraged to include it in generated Patient Summary documents, and support it when received. |
| PS-200 | Immunization.route-Should’nt all concepts be codeable? |
Summary: Should’nt all concepts be codeable?
Existing Wording: Future releases of PS-CA may require use of coded entries. In this release, however, implementations that support codings are encouraged to send the codings for codeable concepts if they are available. Consistent with FHIR best practice, receivers should not produce failures or rejections if codings are received. Proposed Wording: Comment: Should’nt all concepts be codeable? Submitted by: Linda Parisien Canada Health Infoway |
Not Persuasive | CodeableConcepts provide for the provision of text when a code is not available or not appropriate - this is a standard part of FHIR. |
| PS-201 | Immunization-route: Changed for the current valueset definition |
Summary: Changed for the current valueset definition
Existing Wording: Data type CodeableConceptPSCA Binding The route by which the vaccine was administered. Proposed Wording: Data type CodeableConceptPSCA Binding Path taken to administer immunization reference setC Comment: Changed for the current valueset definition Submitted by: Myriam Talantikit Canada Health Infoway |
Not Persuasive with Modification | Keep the basic intent of the text, but update to:
The path or route by which the vaccine was a{*}dministered, as defined in the current valueset{*}.” Should discuss the last clause |
| PS-202 | Immunization-route: Suggestion to remove as not used in Canada |
Summary: Suggestion to remove as not used in Canada
Existing Wording: Additional bindings: • MedicineRouteOfAdministrationUvIps (candidate) Route of immunization administration includes content from EDQM Standard Terms. • v3.RouteOfAdministration (candidate) The path the administered medication takes to get into the body or into contact with the body. While not the preferred terminology for broader pan-Canadian exchange use cases, this additional binding is surfaced to socialize the value sets that may be more commonly in use. Where multiple codings can be supplied, it is encouraged to supply the original coding alongside the pan-Canadian preferred terminology. Constraints • ele-1: All FHIR elements must have a @value or children hasValue() or (children().count() > id.count()) Mappings • v2: RXR-1 • rim: .routeCode • cda: ClinicalDocument/component/StructuredBody/component/section/entry/substanceAdministration/routeCode/code • rim: n/a • v2: CE/CNE/CWE • rim: CD • orim: fhir:CodeableConcept rdfs:subClassOf dt:CD Proposed Wording: delete Comment: Suggestion to remove as not used in Canada - see above Submitted by: Linda Parisien Canada Health Infoway |
Not Persuasive | Keep additional bindings in line with IPS |
| PS-203 | Add Pharmaceuticalbiologicproductandsubstancecode binding to Medication.code.Coding: |
Summary: Add Pharmaceuticalbiologicproductandsubstancecode binding to Medication.code.Coding:
Existing Wording: Proposed Wording: Comment: Add Pharmaceuticalbiologicproductandsubstancecode binding to Medication.code.Coding: Submitted by: CA Core+ Team Infoway |
Persuasive | Pharmaceuticalbiologicproductandsubstancecode binding to Medication.code.Coding as an alternate binding |
| PS-204 | MedicationRequest: Make authoredOn MS |
Summary: Make authoredOn MS
Existing Wording: Proposed Wording: Comment: MedicationRequest.authoredOn CA Core 0..1 MS PS-CA 0..1 non MS (Base FHIR) Make authoredOn MS Submitted by: CA Core+ Team Infoway |
Persuasive | Add MS flag to authoredOn to align with CA Core |
| PS-205 | MedicationStatement- Can PS-CA consider adding PHCVS and HealthConditionCode binding to PS-CA without adding a Must Support flag ? |
Summary: Can PS-CA consider adding PHCVS and HealthConditionCode binding to PS-CA without adding a Must Support flag ?
Existing Wording: Proposed Wording: Comment: Medication Statement.reasonCode binding CA Core+ : PHCVS (Preferred) , HealthConditionCode(Candidate) PS-CA : Condition/Problem/DiagnosisCodes (example) (baseFHIR) Can PS-CA consider adding PHCVS and HealthConditionCode binding to PS-CA without adding a Must Support flag ? Submitted by: CA Core + Team Infoway |
Persuasive | Add a preferred binding to PHCVS with an additional binding of HealthConcernCode (candidate) |
| PS-206 | Observation-SocialHistory.Category - PS-CA should change to 1..*, to match Core since the slice in PS-CA is patterned |
Summary: PS-CA should change to 1..*, to match Core since the slice in PS-CA is patterned
Existing Wording: Proposed Wording: Comment: Observation-SocialHistory.Category CA Core+ 1…* PS-CA 0…* PS-CA should change to 1..*, to match Core since the slice in PS-CA is patterned Submitted by: CA Core + Team Infoway |
Persuasive | Tighten ObservationSocialHistory category element from 0..* to 1..* to align with CA Core+ |
| PS-207 | Make Patient.Address.City MS |
Summary: Make Patient.Address.city MS
Existing Wording: Proposed Wording: Comment: Add MS to Patient.Address.city Submitted by: CA Core + Team Infoway |
Persuasive | Add the MS flag |
| PS-208 | Make Patient.Address.country MS |
Summary: Make Patient.Address.country MS
Existing Wording: Proposed Wording: Comment: Add MS to Patient.Address.country Submitted by: CA Core + Team Infoway |
Persuasive | Add MS flag |
| PS-209 | Make Patient.address.postalCode MS |
Summary: Make Patient.address.postalCode MS
Existing Wording: Proposed Wording: Comment: Add MS to Patient.address.postalCode Submitted by: CA Core + Team Infoway |
Persuasive | Add the MS flag |
| PS-210 | DiagnosticReport.Status Not Fixed in CA Core, Fixed =Final in PS-CA |
Summary: DiagnosticReport.Status Not Fixed in CA Core, Fixed =Final in PS-CA
Existing Wording: Proposed Wording: Comment: DiagnosticReport.Status Not Fixed in CA Core, Fixed =Final in PS-CA IPS CI build changed to not fixed; previously fixed = "final"; PS-CA should change back to not fixed. Submitted by: Kenn Sinn Infoway |
Persuasive | Agreed, the fixed constraint will be removed |
| PS-211 | Imaging Study - PSCA should change binding strength to extensible to align with Core since both ValueSets are the same |
Summary: PSCA should change binding strenght to extensible to align with Core since both ValueSets are the same
Existing Wording: Proposed Wording: Comment: ImagingStudy.procedureCode binding CA Core+ http://radlex.org (extensible) PS-CA RadLex_Playbook.aspx (example) PSCA should change binding strenght to extensible to align with Core since both ValueSets are the same Submitted by: CA Core + Team Infoway |
Persuasive | Update binding to extensible to align with R4 and CA Core.
|
| PS-212 | DiagnosticReport.Category MS - IPS CI build changed to 0..* non MS; previously 1..1 MS; PS-CA should change back |
DiagnosticReport.Category MS and cardinality differences
CA Core+ = 0..* non MS PS-CA = 1..1 MS IPS CI build changed to 0..* non MS; previously 1..1 MS; PS-CA should change back |
Persuasive | Change DiagnosticReport.category to 0..* with no MS |
| PS-213 | Make Patient.Address.line MS |
Summary: Make Patient.Address.line MS
Existing Wording: Proposed Wording: Comment: Add MS to Patient.Address.line Submitted by: CA Core + Team Infoway |
Persuasive | Add MS to the elements to match CA-Core |
| PS-214 | Immunization - vaccineCode |
Existing Wording-
Binding Codes from the National Vaccine Catalogue Vaccine Administered Trade Name Code ValueSet Comment : Confusing ...we should’nt mention the name NVC . NVC brings Infoway’s content and integrate it with additional context and product-specific information needed to make is usable in real-world immunization systems. Use cases: vaccine registry users, prescribing, recording of vaccines, data collection, vaccine coverage surveillance...etc and not for information exchange |
Persuasive with Modification | Remove the strikeout text from the description:
Codes from the -*National Vaccine Catalogue Vaccine*- Administered Trade Name Code ValueSet. Equivalently preferred to the Vaccine Historical Name Code ValueSet, Passive Administered Immunizing Agent Code ValueSet, or Passive Historical Immunizing Agent Code ValueSet found in additionalBinding extension Also, add the following text to the Vocabulary section at the bottom of the page: The National Vaccine Catalogue leverages the Canada Health Infoway SNOMED CT Canadian Edition Immunization Terminology, developed and maintained with the support of the Canadian Public Health Surveillance Community. NVC adds additional product details (such as Health Canada lot numbers, expiry dates, and DINs) to provide a consistent framework for vaccine data in Canada. NVC delivers the integrated, operationally ready content required for standardized data collection, vaccine coverage surveillance, inventory management, and immunization programming in Canada. |
| PS-215 | Immunization - vaccineCode -Typo |
Existing Wording -
Short description Vaccine that was administered or was to be administered. Proposed Wording - Short description Vaccine that was administered or to be administered. Comment : Change to - To be administered |
Not Persuasive | This typo is actually in IPS.
Ticket [https://jira.hl7.org/browse/FHIR-51548] submitted to address The IPS team ruled this Not Persuasive with the following explanation: This issue is not a correction since a "to be administered" immunization would be in the Plan of Care section, not the past immunizations. "Was to be administered" is intentionally included since it applies to vaccines that are deferred (e.g. 'not done' status due to a contraindication). |
| PS-216 | ImmunizationPSCA |
Existing Wording :
additionalBindings added for: IPS VaccineTargetDisease Code VaccineTargetDiseasesUvIps Proposed wording : Delete Comment: The argument for not using UvIPS, is that the VaccinePreventableDiseaseCode is tailored to contain only relevant CA diseases prevented by vaccines. The concepts for diseases in the additional bindings might be numerous that in our CA valueset |
Not Persuasive | Retain the additional bindings, as per discussion.
The primary binding is a preferred binding, which already provides implementer guidance as to the preference |
| Generated at Mon Aug 18 12:24:15 EDT 2025 by Sonia Balgah using Jira 10.3.2#10030002-sha1:0a5d322ae1b7fd5b314be5b31a27d9661f8301b2. |